-
Notifications
You must be signed in to change notification settings - Fork 960
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add contract to migrate a Safe from not L2 to L2 #685
Conversation
Pull Request Test Coverage Report for Build 6578252603
💛 - Coveralls |
Pull Request Test Coverage Report for Build 6626835905Details
💛 - Coveralls |
@@ -0,0 +1,129 @@ | |||
// SPDX-License-Identifier: LGPL-3.0-only |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comment: Completely unrelated to this PR, but maybe it would make sense to group all migration contracts in a contracts/migrations
root directory? Not suggesting doing this as part of this PR, but if I were to jump into the codebase without any context, I would find looking for migration contracts in a separate root slightly more natural and intuitive. Food for thought...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes total sense, I found it weird but I put it on the same directory as the rest of the migrations
@rmeissner Do you think support for migrating v1.1.1 to L2 is required? (I would need to emit |
@nlordell @mmv08 I added a method and a test for migrating from V1.1.1. In that case 2 more steps need to be performed, setting up the according fallback handler and emitting the |
); | ||
|
||
ISafe safe = ISafe(address(this)); | ||
safe.setFallbackHandler(fallbackHandler); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this only happen if the default fallback handler is used? Otherwise it could be unintentionally overwriting a custom fallback handler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, but:
- For the reasons exposed before, it's difficult to know which is the default fallback handler, and more for the 1.1.1 where we didn't do a big follow up on safe-deployments.
- I don't think it will be intended for a user to update to 1.3.1/1.4.1 but still keep their old custom fallback handler.
- This smart contract is done thinking on get the Safe supported on our UI. If they need to use the UI the official fallback handler is required, otherwise for example offchain messages might not work.
- If the user developed a custom fallback handler they should be able to use this contract to set it up back or even a new custom one.
} | ||
|
||
/** | ||
* @notice Migrate from Safe 1.1.1 Singleton to 1.3.1 or 1.4.1 L2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @notice Migrate from Safe 1.1.1 Singleton to 1.3.1 or 1.4.1 L2 | |
* @notice Migrate from Safe 1.1.1 Singleton to 1.3.0 or 1.4.1 L2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ops
- Hardcode nonce 0 in event instead of nonce - 1, should be more gas efficient
For context, we tested it on Polygon:
2 non L2 Safes were created and were converted to L2 Safes:
Thanks @JagoFigueroa ! |
* Add contract to migrate a Safe from not L2 to L2 * Related to safe-global/safe-transaction-service#1703
* Add contract to migrate a Safe from not L2 to L2 * Related to safe-global/safe-transaction-service#1703
This PR implements #781. It migrates the migration contracts from: - #685 - #793 I had to refactor tests quite a bit because a lot has changed since the release of 1.4.1 like we added typechain types, migrated to ethers v6, etc --------- Co-authored-by: Akshay <[email protected]> Co-authored-by: Nicholas Rodrigues Lordello <[email protected]> Co-authored-by: Shebin John <[email protected]> Co-authored-by: Uxío <[email protected]>
This PR implements safe-global/safe-smart-account#781. It migrates the migration contracts from: - safe-global/safe-smart-account#685 - safe-global/safe-smart-account#793 I had to refactor tests quite a bit because a lot has changed since the release of 1.4.1 like we added typechain types, migrated to ethers v6, etc --------- Co-authored-by: Akshay <[email protected]> Co-authored-by: Nicholas Rodrigues Lordello <[email protected]> Co-authored-by: Shebin John <[email protected]> Co-authored-by: Uxío <[email protected]>
This PR implements #781. It migrates the migration contracts from: - #685 - #793 I had to refactor tests quite a bit because a lot has changed since the release of 1.4.1 like we added typechain types, migrated to ethers v6, etc --------- Co-authored-by: Akshay <[email protected]> Co-authored-by: Nicholas Rodrigues Lordello <[email protected]> Co-authored-by: Shebin John <[email protected]> Co-authored-by: Uxío <[email protected]>
Add contract to migrate a Safe from not L2 to L2
nonce=0
, so they are unitialized and the L2 indexer is not missing some configuration changes going on between the update to L2